<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<meta http-equiv="content-type" content="xhtml+xml; charset=utf-8"/>
	<title>about FxIF</title>
</head>
<body>
<h1>What’s it</h1>
<p>FxIF (Firefox exIF) allows you to view meta information data contained in JPEG images from the convenience of your Firefox (or SeaMonkey or other compatible) browser. Most digital cameras add EXIF data to all images you take and much editing software adds or allows you to add more informations on the picture and you the creator.</p>
<p>FxIF is written in JavaScript and XUL, and as such should be portable to all platforms that Mozilla runs on.</p>

<h1>Usage</h1>
<p>After installing FxIF, simply right click on an image, then click <code>FxIF Data</code>. The meta data will be displayed in its own window.<br/>
Note: In the event of the <a href="https://addons.mozilla.org/de/firefox/addon/14228" target="_blank">Element-properties</a> extension—which retrofitts the properties dialogue which was there up to Firefox 3.6—being installed, FxIF integrates itself there.</p>

<h1>Doesn’t work?</h1>
<p>I’d like my extension to work on your system as much as you do. Though sometimes it doesn’t work for you and for changing this I definitely need your help.</p>
<p>For trouble shooting I prefer e-mail. What would be very helpful is where’s the problem exactly (no context menu entry?, no properties dialogue?, no data?, error message?), what other Add-ons you’ve installed, screenshot of the error, output from the Error Console and image you tried to get data from.</p>

<h1>In detail</h1>
<h2>What can it display?</h2>
<p>Meta data that’s contained in JPEG image files in three forms:</p>
<ul>
	<li>binary EXIF data. This is added by most cameras automatically and contains technical informations on the camera model and manufacturer, date and time the image was taken, aperture and shutter speed used, focal length and much much more.</li>
	<li>IPTC-NAA data in a binary structure (IIM). IPTC-NAA comprises a standardized set of fields focusing on informations like the name of the photographer, caption and title for the image, copyright informations, keywords a.s.o.</li>
	<li>XMP (Extensible Metadata Platform). In contrast to aforementioned this data isn’t stored binary but as an XML document within the image and isn’t restricted to only camera or image informations but can hold both and even more. It’s developed by Adobe and pushed by their applications including Photoshop. As said, XMP can hold various informations as all the EXIF data mentioned above and also those from IPTC-NAA as well as application specific.<br/>
  Its advantage is the use of UTF-8 encoding&mdash;so data can be added in every language available&mdash;and also the possibility to hold an information in more than one language simultaneously.</li>
</ul>
<p>Out of the camera most images will only contain binary EXIF data but this may change in future and there’s much software for adding the other informations by you. And software like Photoshop will at least duplicate the EXIF information into XMP data and add data of its own to your image if you just save it&mdash;or at least if you don’t do <em>Save for Web</em>.</p>

<h2>And which fields in detail?</h2>
<p>In detail you can view the following EXIF fields: ImageDescription, Make, Model, LensInfo, LensMake, LensModel, Orientation, ModifyDate/DateTimeOriginal/DateTimeDigitized, Artist, Copyright, Software, ExposureTime., FNumber, ExposureProgram, GPSInfo, ISO, ShutterSpeedValue, ExposureCompensation, MaxApertureValue, SubjectDistance, MeteringMode, LightSource, Flash, FocalLength, UserComment, ExifImageWidth, ExifImageLength, FocalPlaneXResolution, FocalPlaneResolutionUnit. ExposureMode, WhiteBalance, DigitalZoomRatio, FocalLengthIn35mmFormat, ColorSpace</p>
<p>Also following fields are taken from IPTC-NAA: By-line, Caption-Abstract, Headline, Instructions, CopyrightNotice, City, Sublocation, Province/State and Country</p>
<p>And the following from XMP: dc:Creator, photoshop:Headline, dc:title, dc:description, dc:rights, xmpRights:UsageTerms, cc:license, photoshop:City, Iptc4xmpCore:Location, photoshop:State, photoshop:Country, tiff:Make, tiff:Model, aux:Lens, exif:DateTimeOriginal, exif:DateTimeDigitized, exif:FNumber, exif:ApertureValue, exif:FocalLength, exif:FocalLengthIn35mmFilm, exif:SubjectDistance, exif:ExposureTime, exif:Flash, tiff:Orientation, exif:ExposureBiasValue, exif:WhiteBalance, exif:LightSource, exif:MeteringMode, exif:ExposureProgram, exif:ExposureIndex, exif:ExposureMode, exif:ISOSpeedRatings, exif:DigitalZoomRatio, exif:GPSAltitude, exif:GPSAltitudeRef, exif:GPSLatitude, exif:GPSLongitude, exif:GPSImgDirection, exif:GPSImgDirectionRef, exif:ColorSpace, photoshop:ICCProfile, photoshop:Instructions, xap:CreatorTool, softwareAgent in mm:History</p>
<p>Additionally the JFIF comment field is interpreted.</p>
<p>That said, not all data is displayed always and at once. First not all files contain all fields. And second if fields that exist to hold the same information like the photographers name or description of the image are present in more than one structure, the information is only displayed once. The priority in which they’re used is XMP, IPTC-NAA, EXIF in descending order.</p>
<p>Also for your convenience if GPS coordinates are available in the EXIF fields, a weblink to a map provider is displayed behind them. At least it is in Firefox 3 and SeaMonkey 2 because earlier don’t support the technique used. And be aware that these are the coordinates of the camera, not the object photographed which can differ significantly especially for tele photos.</p>

<h2>That’s not that much, why not more?</h2>
<p>FxIF wants to give you the informations which most people most likely want to see when viewing an image in the browser. That is a quick look when, by which camera with which settings, where and some informations on the subject.</p>
<p>There are other applications that give you any possible information found in the image. But from our point of view their purpose is different and doesn’t make much sense in the browser. Displaying all informations available in the file can simply be overwhelming and makes the basic informations hard to find.</p>

<h2>And why only in JPEG images?</h2>
<p>That image format is by far the most common and concentrating on it keeps the extension simple.</p>

<h2>Where is it supposed to run on?</h2>
<p>As mentioned earlier it’s written in JavaScript and XUL, so it should run in combination with the GRE (Gecko Runtime Environment) everywhere GRE runs.</p>
<p>Out of the box the extension is made for the Firefox browser from version 0.10 on, the Mozilla Application suite from version 1.7 on and its successor SeaMonkey from version 1.0 on.</p>

<h2>How much does it cost?</h2>
<p>Nothing. It’s free software in terms of the Free Software Foundation. It’s triple licensed as MPL 1.1, GPL 2.0, LGPL 2.1 and like most extensions for the Mozilla platform comes with the source code in the XPI file itself.</p>

<h1>Configure me</h1>
<p>Since likings are different we decided to make two functions configurable. You can do this via the options dialog on the Add-on Manager (available in Firefox and SeaMonkey 2) or by directly manipulating the respective pref.</p>
<p>First option is to choose the format used for displaying coordinates. This is either Degrees Minutes (DM), Degrees Minutes Seconds (DMS) like 40&deg;&nbsp;43&prime;&nbsp;20.7&Prime;&nbsp;N, 74&deg;&nbsp;02&prime;&nbsp;47.2&Prime;&nbsp;W or decimal degree (DD) like 40.722417&deg;&nbsp;N, 74.046444&deg;&nbsp;W. Any informations are rounded to two decimal places in DM/DMS and six decimal places in DD format. The associated pref is <code>extensions.fxif.gpsFormat</code> where 0 means DMS, 2 DM, and 1 DD.</p>
<p>The other option is the map provider to use for the weblink. The default (when the pref isn’t available or empty) is to use <code>openstreetmap.org</code>, but as I wrote, likings are different.</p>
<p>So to change it, insert any URL into the field (or pref). You can use really any URL, but to have the respective coordinates used, put a <code>%lat%</code> anywhere the latitude shall be inserted and <code>%lon%</code> anywhere the longitude shall be inserted.</p>
<p>So the default is</p>
<p><code>http://www.openstreetmap.org/?mlat=%lat%&amp;mlon=%lon%&amp;layers=M</code></p>
<p>but if you want to use Google as a map provider, insert for example</p>
<p><code>http://maps.google.com/maps?ll=%lat%,%lon%&amp;q=%lat%,%lon%&amp;hl=%lang%</code></p>
<p>or for Yahoo use</p>
<p><code>http://maps.yahoo.com/#mvt=m&amp;lat=%lat%&amp;lon=%lon%</code></p>
<p>or</p>
<p><code>http://atlas.mapquest.com/maps/map.adp?searchtype=address&amp;formtype=latlong&amp;latlongtype=decimal&amp;latitude=%lat%&amp;longitude=%lon%</code></p>
<p>for MapQuest a.s.o. In URL langitude and longitude will always get inserted in unrounded decimal format.</p>
<p>Noticed the <code>%lang%</code> in the Google Maps URL? This is the third placeholder available and will be replaced by the content language code you’ve chosen in your general browser settings. It’s not necessary but at least in case of Google offers the site in your language.</p>
<p>You can also add another parameter which is “z=” for Google or “zoom=” for OpenStreetMap and Yahoo! if you don’t like the providers standard zoom setting. Simply write a zoom level after the equal sign (interesting levels should be around 15).</p>
<p>The associated pref is <code>extensions.fxif.mapProvider</code>.</p>

<h1>Are there localized versions?</h1>
<p>FxIF is already available in Brazilian Portuguese, Chinese (simplified as well as traditional), Czech, Dutch, English, French, German, Italian, Japanese, Polish, Russian and Spanish. The one used depends on the browsers locale.</p>
<p>If you don’t find your language in the list, you’re welcome to do a translation and donate it. You can get the <a href="http://code.google.com/p/fxif/source/browse/trunk/locale/en-US">english version .dtd and .properties files</a> from the FxIF repository and mail us the translated file for inclusion. Also fixes for errors in translations are welcome.</p>
<p>FxIF also has a page on <a href="http://www.babelzilla.org/index.php?option=com_wts&extension=5292&type=show" target="_blank">BabelZilla.org</a> where translations are organized. You can add translations there as well.</p>

<h1>I’ve found a bug</h1>
<p>That happens. You can send <a href="mailto:ch.ey@gmx.net">me</a> a mail about it. Or add an issue on the <a href="http://code.google.com/p/fxif/issues/list" target="_blank">Google Code project</a>. I’ll look into it then.</p>

<h1>When will the next version be released?</h1>
<p>Like most projects “when it’s done”. Since 0.2.3 the FxIF code has its <a href="http://code.google.com/p/fxif/">home at Google Code</a> and the source kept online can be <a href="http://code.google.com/p/fxif/source/checkout">checked out via svn</a>.</p>

<h1>Version history</h1>
<h2>What’s new in 0.30</h1>
<ul>
	<li>Displaying of GPS coordinates</li>
	<li>Decoding of IPTC-NAA and XMP data</li>
	<li>Decoding of creator, title, description and copyright</li>
	<li>Ability to operate on images opened from mailbox, news and imap</li>
  <li>Also works with Firefox >= 3 and SeaMonkey >= 2</li>
  <li>Also works with images that aren’t cached.</li>
</ul>
<h2>What’s new in 0.3.1</h1>
<ul>
	<li>Also works in Firefox >= 3.6 where the properties dialogue has been removed.</li>
</ul>
<h2>What’s new in 0.3.2</h1>
<ul>
	<li>A few bugfixes, among them is “All toolbars disappear on closing print preview”.</li>
</ul>
<h2>What’s new in 0.4</h1>
<ul>
	<li>Added interpretation of EXIF values that are contained in XMP format rather than in old binary format. Added some fields mainly regarding the location of the subject. Internally more fields are inspected to fill the license field.</li>
	<li>Also rearranged the order of the field listing, fixed some bugs in the XMP interpreter and the binary EXIF reader.</li>
	<li>Own EXIF window is now closable with ESC and the Copy button has an Alt+C (Option+C on Mac) shortcut.</li>
	<li>Can now cope with images delivered compressed (e.g. "Content-Encoding: gzip")</li>
	<li>Enabled overlaying of the properties window that’s being readded by Geoff Lankows <a href="https://addons.mozilla.org/de/firefox/addon/14228" target="_blank">Element properties</a></li>
	<li>Added new translation for Russian thanks to Max Pozdeev. All localizations have been overhauled, thanks to old and new contributors on <a href="http://www.babelzilla.org" target="_blank">BabelZilla</a>.</li>
</ul>
<h2>What’s new in 0.4.1</h1>
<ul>
	<li>Only use DateTime if no DateTimeOriginal or DateTimeDigitized are available.</li>
	<li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=3" target="_blank">Issue 3</a>: Relaxed detection of XMP data a bit to work around a bug in some photo software.</li>
	<li>Not existing flash information in XMP data doesn’t cause fail of XMP evaluation anymore.</li>
	<li>Made evaluation of following data not fail if some error occurs. Instead a note is placed in the window that evaluation stopped and data shown might be incomplete.</li>
	<li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=2" target="_blank">Issue 2</a>: a bug where "chr" was used as language if the pref intl.accept_language was left at the default for the browser. (Thanks to Hector Zhao)</li>
	<li>Added new translation for Dutch thanks to markh van BabelZilla.org.</li>
</ul>
<h2>What’s new in 0.4.2</h1>
<ul>
	<li>Flash data from XMP is now better evaluated (also as child values of the Flash tag instead only attributes of it). Thanks to Phil Lattimore for reporting.</li>
  <li>At least one software appends a null byte to the XMP document and the Mozilla XML parser doesn’t like this at all. I added a workaround for this case which shortens the document by one byte.</li>
</ul>
<h2>What’s new in 0.4.3</h1>
<ul>
	<li>Fixed some reads which were to optimistic on the bytes contained in a JPEG marker which could lead to negative byte counts tried to be read (and causing the stream reader to bail out). Thanks to Jemini for reporting.</li>
	<li>Fixed a bug preventing to catch and report it the aforementioned bug correctly to the user.</li>
  <li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=4" target="_blank">Issue 4</a>: ”Copy“ button does not copy GPS coords.</li>
  <li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=5" target="_blank">Issue 5</a>: EXIF tag Orientation with unknown value caused FxIF to bail out.</li>
  <li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=6" target="_blank">Issue 6</a>: Dates from binary EXIFs where copied verbatim containing colons as separators. These are now replaced by hyphens to match the date formatting for binary IPTC and XMP dates (YYYY-MM-DD as recommended in ISO 8601).</li>
  <li>Also dates comming from binary EXIF don’t carry timezone informations. This is now mentioned.</li>
  <li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=8" target="_blank">Issue 8</a>: Support for Degrees Minutes (DegMin) GPS format.</li>
  <li>Reworked flash data evaluation and strings on basis off a patch by Max Pozdeev.</li>
  <li>Added new translations for Swedish by Jan Kardell (via BabelZilla.org) and for Finnish by Ilari Oras (fixing <a href="http://code.google.com/p/fxif/issues/detail?id=9" target="_blank">Issue 9</a>).</li>
  <li>Polish translation is not contained since newly added strings weren’t translated.</li>
  <li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=10" target="_blank">Issue 10</a>: Endless recursion if Exif Interoperability Offset or Exif Offset point to its own start offset. That’s an error in the data.</li>
</ul>
<h2>What’s new in 0.4.4</h2>
<ul>
  <li>Reading of informations about lens (from binary Exif, XMP data has already been read in the past) and used software.</li>
  <li>Dropping Support for the old Mozilla Suite. It’s dead for quite some time and no one should use it for his or her own good anymore anyway.</li>
  <li>At least in Gecko 2 (Firefox 4, SeaMonkey 2.1) the XML parser became picky about non-ASCII characters not correctly encoded as UTF-8 or Unicode. Some images do contain such documents which violate XMP specification (and actually XML specification too). I inserted a workaround which makes a second try after converting non-ASCII characters. This can lead to wrong display of such chars in buggy files, but they’re at least parsable this way.</li>
  <li>Ctrl+W, resp. Cmd+W now closes FxIF’s own dialogue (like Esc already does since version 0.4).</li>
  <li>FxIF’s own window now behaves like when the data is shown in the browsers own property window (resp. that of the <a href="https://addons.mozilla.org/de/firefox/addon/14228" target="_blank">Element-properties</a> extension). I.e. it’s now possible to have multiple FxIF windows open in parallel instead reusing one.</li>
  <li>Improved IPTC date handling: If IPTC only contains either date or time, only use it if there’s no date already set.</li>
  <li>JFIF comments are now displayed</li>
  <li>Added new translation for Turkish thanks to contributor omrakin on <a href="http://www.babelzilla.org" target="_blank">BabelZilla</a> and polish translation is included again.</li>
</ul>
<h2>What’s new in 0.4.5</h2>
<ul>
	<li>Fixed a bug which caused the browser to hang hard. Thanks to Radek Docekal for notifying.</li>
  <li>Fixed a bug which displayed a FxIF Data window with all fields but without any data. It was triggered by images using a <map>. Thanks to Joop Nijenhuis for notifying.</li>
  <li>If the mapProvider pref isn’t set, a default is used but wasn’t filled in the corresponding input field in the options. This is now done.</li>
  <li>Among the fields evaluated for the designation of the software used for creating the photo is the XMP field CreatorTool. When present it overwrote the value in the EXIF field Software. But CreatorTool only contains (at least following the specification) the software used for originally creating the photo, not the last version (like it should in the EXIF field Software).<br />
So now also the field softwareAgent (in the History list) is evaluated and its last list entry is used for displaying the software. Also the field CreatorTool is only used if the EXIF field Software isn’t present.</li>
  <li>More lens information are read from Canon Maker Notes.</li>
</ul>
<h2>What’s new in 0.4.6</h2>
<ul>
  <li>Fixed a bug in interpreting Canon Maker Notes. FxIF used the byte order of the EXIF fields for it but it seems Canon Maker Notes are always in Intel byte order (Little-Endian).</li>
  <li>Fixed another bug in interpreting Canon Maker Notes. It seems there exists software which moves Maker Notes within the image file, modifying the pointers into that block, but not the offsets within the Maker Notes. Because of this FxIF now adjusts those offsets using the Maker Notes Footer. Thanks to Phil Harveys Image-Exif-Tools for this insight.</li>
  <li>Preferences used by FxIF are now added to the sync whitelist. That means the FxIF options now get synced using <a href="https://support.mozilla.org/en-US/kb/firefox-sync-take-your-bookmarks-and-tabs-with-you" target="_blank">Firefox-Sync</a>.</li>
  <li>FxIF now stops reading strings if encountering a null byte. Until now the given number of chars where read and a null byte just filtered. Thanks to Dennis van den Broek for providing the sample image that uncovered that bug.</li>
  <li>FxIF now interprets the direction the camera pointed if that information is present. Thanks to Dennis van den Broek for providing the sample images.</li>
  <li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=18" target="_blank">Issue 18</a>: Fixed bad regex which matched too much.</li>
</ul>
<h2>What’s new in 0.4.7</h2>
<ul>
  <li>"Fixed" <a href="http://code.google.com/p/fxif/issues/detail?id=19" target="_blank">Issue 19</a>: Deactivated alerting the user on parse error of the XMP document. There is no workaround I know of as long as FxIF is using Mozillas DOM parser. And I don’t want to go implementing my own.</li>
  <li>Exception occured when there was an empty GpsImgRef field in EXIF or XMP or if it was other than M or T.</li>
  <li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=17" target="_blank">Issue 17</a>: Endless recursion if Exif Interoperability Offset or Exif Offset point to a directory that has been processed before. It’s similar but more complex to Issue 10 which has been fixed in FxIF 0.4.3.</li>
  <li>Fixed a bug that had the effect that the creator data (formerly photograph) wasn't shown anymore. I renamed a variable in one place instead all occurences. Many thanks to Oliver Theobald for finding the bug.</li>
  <li>In at least one image the ISO value isn’t contained as integer, as it's specified, but as string. FxIF nevertheless handled it as integer, bailed out and so the rest of the data wasn't evaluated. So for this and another field where this might happen too I added a workaround. Many thanks to Aaron Gullison for finding the bug.</li>
  <li>Evaluating the EXIF fields Aperture and MaxAperture was wrong – and that at least since version 0.2.3. I assume an error in porting the relevant code from Jhead (which is written in C). Different from the field FNumber the value isn’t used directly but computed using a formula which I don’t pretend to understand, neither the reason for using it, but ported correctly the result is the expected one. Many thanks to Babar de Saint Cyr for finding the bug.</li>
  <li>According to the EXIF 2 specification the EXIF field UserComment offers the posibility to encode the string in ASCI, JIS, UNICODE and self defined coding. Until now FxIF just interpreted everything as ASCII and only displayed the character code in case of other codings. Now FxIF understands ASCII and UNICODE for this field. In case of other codings the content will be displayed as ASCII string. Many thanks to Babar de Saint Cyr for finding the bug. That bug was also reported as <a href="http://code.google.com/p/fxif/issues/detail?id=20" target="_blank">Issue 20</a>.</li>
  <li>Added new translation for Hungarian thanks to contributor Szilárd Andai.</li>
</ul>
<h2>What’s new in 0.4.7.1</h2>
<ul>
  <li>Code from the next in-development-version slipped in, sizing up the page info dialogue in an unfashionable manner. This code has been removed. That bug was also reported as <a href="http://code.google.com/p/fxif/issues/detail?id=21" target="_blank">Issue 21</a></li>
</ul>
<h2>What’s new in 0.4.8</h2>
<ul>
  <li>Some piece of software unfortunately leaves out the pascal string from the 8BIM header of binary IPTC data. By this the IPTC properties is shifted and confuses decoders (also the phantastic exiftool). FxIF now has an additional plausibility check and a mechanism to recover from the problem. Many thanks to Oleg V. Samsonov for reporting.</li>
  <li>There are images containing invalid offsets for branches to EXIF sub directories. In the case at hand it’s offset 0, but others are possible. Therefore I now added various checks in different places against something like that. Many thanks to Alice Cheung for reporting.</li>
  <li>Some images contain EXIF UserComments consisting purely of null bytes. And these comments have been displayed as such. Hm, I changed the handling of null bytes in strings for version 0.4.6. But for an other fix I implemented a similar function and accidentally used the new instead of the old in one place. Now the right function is used. Thanks again to Dennis van den Broek for reporting.</li>
  <li>At least one piece of software doesn’t write EXIF attributes in XMP format as specified but in full human readable form. E.g. for exif:FNumber not „35/10“ but „f/3,5“, for  exif:ExposureProgram even „Zeitautomatik“ instead of „4“ . FxIF now checks the format the value is in. If it isn’t, the value won’t be interpreted but used 1:1 — but only if the property hasn’t been filed, e.g. from binary EXIF property. Many Thanks to Heino Tiedemann for reporting and the test image.</li>
  <li>The EXIF value DigitalZoomRation was never displayed when contained as XMP value although it should have been. It’s now displayed if > 1.</li>
  <li>A test to protect against reading an array does indeed work, but led to canceling the whole evaluation and reported a heavy error to the user. For there’s no sensible workaround, I lowered the severity of this error and it now simply ignore the value which would lead to reading outside the array. Many Thanks to Heino Tiedemann for reporting and the test image.</li>
  <li>Removed a workaround in the codebase which (as stated) “Fixes strange encoding on some older digicams.” and multiplies every ISO value below 50 by 200. This came from the jhead tool which FxIF was based on. The workaround was removed there with version 2.97. That bug was also reported as <a href="http://code.google.com/p/fxif/issues/detail?id=22" target="_blank">Issue 22</a>.</li>
  <li>Fixed <a href="http://code.google.com/p/fxif/issues/detail?id=23" target="_blank">Issue 23</a>: For Images in which the time of creation (field TimeCreated in the binary IPTC data) contains no time zone information no time information was output at all. This comes from tightly following the specification in which time zone information is mandatory. In the new version this information is optional. If it isn’t contained, the output contains a note. The same case has been fixed for time informations in the XMP data.</li>
</ul>
<h2>What’s new in 0.4.9</h2>
  <li>Manfred Härtel correctly mentioned to me, that GPS coordinates displayed by FxIF where less precise when in the format of Degree, Minutes than in the other two formats (Degree and Degree, Minutes, Seconds). Therefore FxIF now displays 4 decimal places for this format.</li>
  <li>Since no encoding is specified for strings in binary EXIF data, FxIF just displayed EXIF strings 1:1. But by now even the MWG recommends to use UTF-8 coding for EXIF strings and some software does this. This had the effect, that former versions of FxIF displayed only garbage instead of special characters in this cases. This has been changed now by FxIF assuming each EXIF string to be UTF-8 coded and only falls back to directly displaying it if in a string at least one not-UTF-8-coded special char is encountered. Many thanks to Tobias Kühne for the suggestion and the example image.</li>
  <li>I was informed, that FxIF 0.4.8 shows very few EXIF data in images written by Lightroom 6/CC. The cause was a security check I added in version 0.4.8 which was a bit too tight. The images written by that software from most other in the fact that its Exif SubIFD comes <strong>before</strong> the IFD0. This very unusual but completely ok. I’ve now loosened that security check and FxIF works again as in prior versions. Many thanks for reporting to Fred Hönig and Toshik for reporting and providing a test image.</li>
<ul>
</ul>
<h2>What’s new in 0.5</h2>
<ul>
  <li>Fixed a bug in interpreting Canon Maker Notes. FxIF used the byte order of the EXIF fields for it but it seems Canon Maker Notes are always in Intel byte order (Little-Endian).</li>
	<li>Support for Maker Notes. Maker Notes are a pain to implement and the format in the binary Exif is dead ugly because the formats of the informations do not only vary between manufacturers but also between models. The now supported Lens Type informations for Canon, Nikon, Pentax and Sony have x variations. Also those type informations aren’t written into the file as text but coded as some number. Decoders like FxIF rely on work of volunteer with these lenses to provide test images because these numbers aren’t documented officially. Also not all camera models provide e.g. lens informations.</li>
	<li>Added new translations for Ukranian thanks to contributor Yaroslav Krytsun on <a href="http://www.babelzilla.org" target="_blank">BabelZilla</a> and traditional Chinese thanks to Rock Yang.</li>
</ul>
</body>
</html>